Computing systems often include one or more host computers (“hosts”) for processing data and running application programs, direct access storage devices (DASDs) for storing data, and a storage controller for controlling the transfer of data between the hosts and the DASD. Storage controllers, also referred to as control units or storage directors, manage access to a storage space comprised of numerous hard disk drives, otherwise referred to as a Direct Access Storage Device (DASD). Hosts may communicate Input/Output (I/O) requests to the storage space through the storage controller.
Some disaster recovery systems address data loss over a period of time, in which case writes to volumes on data storage may be lost. The writes may update data, write new data, or write the same data again. To assist in recovery of data writes, a copy of data may be provided at a remote location. Such copies may also be referred to as dual or shadow copies.
The remote mirroring systems provide techniques for mirroring data in order to facilitate recovery after a system failure. Such data shadowing systems can also provide an additional remote copy for non-recovery purposes, such as local access at a remote site.
In remote mirroring systems, data is maintained in volume pairs. A volume pair is comprised of a volume in a primary storage device and a corresponding volume in a secondary storage device that includes a copy of the data maintained in the primary volume. Typically, the primary volume of the pair will be maintained in a primary direct access storage device (DASD) and the secondary volume of the pair is maintained in a secondary DASD shadowing the data on the primary DASD. A primary storage controller may be provided to control access to the primary DASD and a secondary storage controller may be provided to control access to the secondary DASD.
Volumes in the secondary DASDs are consistent when all writes have been transferred in their logical order, i.e., all dependent writes transferred first before the writes dependent thereon. In the banking example, this means that the deposit is written to the secondary volume before the withdrawal. A consistency group is a collection of related volumes that need to be kept in a consistent state. A consistency transaction set is a collection of updates to the primary volumes such that dependent writes are secured in a consistent manner. Consistency groups maintain data consistency across volumes.
In many systems, data on one storage device, such as a DASD, may be copied to the same or another storage device so that access to data volumes can be provided from two different devices. A point-in-time copy involves physically copying all the data from source volumes to target volumes so that the target volume has a copy of the data as of a point-in-time. A point-in-time copy can also be made by logically making a copy of the data and then only copying data over when necessary, in effect deferring the physical copying. This logical copy operation is performed to minimize the time during which the target and source volumes are inaccessible.
A number of direct access storage device (DASD) subsystems are capable of performing “Instant Virtual Copy” (IVC) operations, also referred to as “fast replicate functions.” Instant virtual copy operations work by modifying metadata in structures, such as relationship tables or pointers, to treat a source data object as both the original and copy. In response to a host's copy request, the storage subsystem immediately reports creation of the copy without having made any physical copy of the data. Only a “virtual” copy has been created, and the absence of an additional physical copy is completely unknown to the host.
Later, when the storage system receives updates to the original or copy, the updates are stored separately and cross-referenced to the updated data object only. At this point, the original and copy data objects begin to diverge. The initial benefit is that the IVC occurs almost instantaneously, completing much faster than a normal physical copy operation. This frees the host and storage subsystem to perform other tasks. The host or storage subsystem may even proceed to create an actual, physical copy of the original data object during background processing, or at another time.
One such IVC operation is known as a FlashCopy® operation. A FlashCopy® operation involves establishing a logical point-in-time relationship between source and target volumes on the same or different devices. The FlashCopy® operation guarantees that until a track in a FlashCopy® relationship has been hardened to its location on the target disk, the track resides on the source disk. A relationship table is used to maintain information on all existing FlashCopy® relationships in the subsystem. During the establish phase of a FlashCopy® relationship, one entry is recorded in the source and target relationship tables for the source and target that participate in the FlashCopy® being established. Each added entry maintains all the required information concerning the FlashCopy® relationship. Both entries for the relationship are removed from the relationship tables when all FlashCopy® tracks from the source extent have been physically copied to the target extents or when a withdraw IVC command is received. In certain cases, even though all tracks have been copied from the source extent to the target extent, the relationship persists.
The target relationship table further includes a bitmap that identifies which tracks involved in the FlashCopy® relationship have not yet been copied over and are thus protected tracks. Each track in the target device is represented by one bit in the bitmap. The target bit is set (e.g., either logically or physically) when the corresponding track is established as a target track of a FlashCopy® relationship. The target bit is reset when the corresponding track has been copied from the source location and destaged to the target device due to writes on the source or the target device, or a background copy task.
Once the logical relationship is established, hosts may then have immediate access to data on the source and target volumes, and the data may be copied as part of a background operation. A read to a track that is a target in a FlashCopy® relationship and not in cache triggers a stage intercept, which causes the source track corresponding to the requested target track to be staged to the target cache when the source track has not yet been copied over and before access is provided to the track from the target cache. This ensures that the target has the copy from the source that existed at the point-in-time of the FlashCopy® operation. Further, any destages to tracks on the source device that have not been copied over triggers a destage intercept, which causes the tracks on the source device to be copied to the target device.
A consistency group created command acts on a logical subsystem, while an establish FlashCopy® freeze command is used for consistency group creation, and is done on a volume by volume basis. Each establish FlashCopy® freeze command is processed individually, and this creates a delay if there is the desire to create a consistency group with multiple volumes. Consistency groups are formed on a logical subsystem (LSS) basis. In order to form consistency groups, a user first issues an establish FlashCopy® freeze command to the volumes to be in a consistency group, then, the user issues a consistency group created (unfreeze) command for each logical subsystem in the consistency group. Because the unfreeze command is issued after all of the freeze commands have successfully executed, there can be a delay as more and more volumes are within a single consistency group. For example, to put a large number of volumes (e.g., multiple thousands of volumes) into a consistency group may be in the order of several minutes. However, internally, when a freeze command is received, Input/Output (I/O) is held off by putting volumes in a long busy state until the unfreeze command arrives (at which point the volumes are removed from the long busy state) or until a 1-2 minute timer expires. It is possible, then, that if there are too many volumes in a consistency group, the unfreeze command may arrive after some of the volumes' timer expires, and the consistency group is not formed.
Also, internally, a quiesce mechanism is initiated for the freeze. Once the I/O drains, the freeze process begins. The quiesce process requires a Task Control Block (TCB) to wait for the drain to complete. The TCB is allocated in addition to the normal TCB used for the chain itself (the start Input/Output (I/O) TCB).